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Section 1 


INTRODUCTION 


1.1 PURPOSE AND SCOPE 


This volume presents an executive summary of the final report of 
the Space Station (SS) Mission Planning System (MPS) Development Study, NASA 
Contract NAS8-37275. 

Sections 2 through 5 contain summaries of the activities, 
methodologies, achievements, and results of the major study tasks. The final 
section provides a summary of major conclusions and recommendations. 

1.2 STUDY OBJECTIVES 

The basic objective of the SS MPS Development Study was to 
define a baseline Space Station mission planning concept and the associated 
hardware and software requirements for the system. Specific objectives in 
support of the basic objective were the following: 

a. Develop a mission planning concept which is consistent with 
the overall Space Station operations philosophy. 

b. Define and assess the capability of the Spacelab mission 
planning system for use in Space Station mission planning consistent with the 
concept developed under objective a. 

c. Determine and recommend where Artificial Intelligence (AI) 
concepts and techniques can be effectively utilized for Space Station mission 
planning. AI areas to be investigated for application to the specific 
requirements of mission planning Include natural language interfaces, expert 
systems, and automatic programming. 

d. Construct a software development plan for a phased 
development of a Space Station mission planning system. The plan shall 
consider the modifications identified in objective b, and the implementation 
of any AI concepts recommended in objective c. The plan shall include a 
schedule and a manpower estimate. 

1 . 3 TECHNICAL APPROACH 


The SS MPS Development Study Included the following tasks to 
accomplish the study objectives: 


Task 1 
Task 2 

Task 3 

Task 4 

Task 5 


Orientation 

Review Spacelab Mission Planning 

Process and Software 

Space Station Mission Planning 

Software Requirements 

Investigate Artificial Intelligence 

Applications to Mission Planning 

Mission Planning Software Development Plan 


The flow of these tasks is reflected in Figure 1.3-1. 
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Task 1 allowed the study team to obtain an initial 
familiarization with the process and existing software used for Spacelab 
payload mission planning at MSFC and to travel to other NASA centers to obtain 
a general familiarization with the processes and software in use for mission 
planning at those centers. 

The objective of Task 2 was to establish a complete baseline 
definition of the Spacelab payload mission planning process, along with a 
definition of existing software capabilities for potential extrapolation to 
the Space Station era. Areas which were included were orbital mechanics 
analysis and planning, mission timeline generation, data flow analysis and 
planning, onboard computer timelines generation and implementation, 
experiments command planning and implementation, and planning for Payload 
Operations Control Center (POCC) support. Preflight planning and real-time 
planning and replanning activities were also defined. The process definition 
was defined using detailed functional flow diagrams, and individual software 
module functions. 

Task 3 used the Information developed in Task 2 for the Spacelab 
payload mission planning process and software as the basis for defining 
requirements to support Space Station mission planning. The system was 
designed to permit the mission planning function to be centralized or 
distributed, and to be performed by non-expert mission planners as well as 
experts. The role of mission planning onboard the Space Station and the 
interfaces with the ground were assessed. Initially, five Space Station 
mission planning concepts were identified for assessment; these ranged from 
all mission planning done on the ground to all mission planning done on-board 
the Space Station. Subsequent MSFC guidance narrowed the possible concepts 
to one in which mission planning was to be done on the ground with minor 
real-time replanning capability to be provided on-board. Comparable to the 
Spacelab process, detailed flow diagrams of the Space Station mission planning 
concept were developed, Including the flow of planning data. Also, software 
functions were Identified, and modifications/additions to the Spacelab payload 
mission planning system software to support the Space Station mission planning 
concept were defined. 

In Task 4, the Space Station mission planning concept (developed 
in Task 3) was reviewed for the purpose of identifying areas where Artificial 
Intelligence (AI) concepts might offer substantially improved capability. 

Three specific AI concepts were investigated for applicability: natural 

language interfaces, expert systems, and automatic programming. The 
advantages and disadvantages of interfacing an AI language with existing 
FORTRAN programs or of converting totally to a new programming language were 
identified. 
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Task 5 integrated the outputs of Task 3 and 4 to produce the 
primary product of the Study, a Space Station Mission Planning System Software 
Development Plan. The plan includes: 

o A detailed description of modifications and additions to 
the Spacelab mission planning system which are required in order to make this 
system suitable for use in Space Station mission planning. 

o Recommendations on the use of AI as means of improving 
the overall mission planning process, including identification of specific 
areas where AI may be beneficial. 

o A development schedule compatible with the overall Space 
Station schedules, and the manpower required. 

The development plan includes a description of the Space Station 
mission planning concept, a review of the functions to be performed, and a 
description of the modules required for each function. Module development 
standards, such as language used for coding, are also defined. 
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Section 2 


SPACELAB MISSION PLANNING PROCESS AND SOFTWARE 
2.1 ACTIVITIES AND ACCOMPLISHMENTS 


The purpose of Task 2 was to review the current Spacelab (SL) 
payload mission planning process and software and to develop a complete 
definition and understanding of the process and Mission Integration Planning 
System (MIPS). The approach taken for this task was first to develop an upper 
level Spacelab functional flow diagram, then to group the major activities 
from the overall diagram into major functional areas of activity (which tended 
to correspond to MSFC mission planning organizational elements), and finally, 
for each functional area, to develop detailed flows to a level sufficient to 
acquire a thorough understanding of the mission planning activities and to be 
able to correlate the capability of a SL MIPS software module to the objective 
of a specific activity. Based on knowledge gained, a computerized data base 
of mission planning activities, activity descriptions, and resource data was 
also developed. 

The major inputs to the task were MSFC briefings, demonstrations 
and handout materials, Spacelab mission planning process and software 
documentation, and personal Interviews with Spacelab mission planning 
personnel. By far the most valuable of these Inputs were the 
Interviews/working sessions with mission planning personnel for development of 
the functional flows. Mission planning personnel also made certain inputs to 
the data base which could only be provided by people who were experienced in 
the SL mission planning process. The support of these NASA personnel was 
essential in accomplishing this task. 

The major products of this task were the Spacelab mission 
planning process functional flow diagrams and Spacelab MIPS data base. These 
products, and the knowledge gained from their development served as a 
significant input to Task 3 because they identified not only the SL Payload 
MIPS software modules of potential applicability to Space Station, but also a 
detailed understanding of the scope, nature, and sequence of activities and 
inputs/outputs that are required for the planning of payload on-orbit 
operations in general. 

This task revealed certain characteristics and lessons learned 
from the Spacelab payload mission planning that served as important 
considerations in the establishment of the fundamental objectives and approach 
toward Space Station mission planning in Task 3. These characteristics and 
lessons learned are presented below: 

o Spacelab mission planning activities are centralized. 

o Payload activities are scheduled down to the minute to make 
maximum utilization of resources during a short-duration 
mission. 

o The collection of principal investigator experiment 

operations requirements is a very sizable manual effort 
which continues through all planning cycles. 
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o Spacelab mission planning employs a system of 58 actively 
used computer programs which have evolved over a ten-year 
period without the benefit of a rigidly controlled, 
structured process of development (Upgrading of 
capabilities is still underway). 

o Though employing computer software, the Spacelab mission 
planning process involves considerable manual effort of 
highly skilled personnel. 

o User-friendly interactive and automated software is 

considered of key importance to reducing mission planning 
manpower requirements. 

2.2 FUNCTIONAL FLOW DIAGRAMS 

2.2.1 Spacelab Functional Flow Diagram 

An upper level Spacelab Functional Flow Diagram (Figure 2.2. 1-1) 
was developed in order to identify all major activities of the Spacelab 
payload mission planning process. The diagram shows Interfaces required by 
the planning center (MSFC) with the Principal Investigators (Pi's) and with 
the STS center (JSC). The diagram includes activities ranging from payload 
data collection, through the required analyses, to preparation of payload 
mission execution documentation. The activities for three (3) planning cycles 
(preliminary, basic, update) are encompassed by the flow except where noted by 
the diagram legend. Real-time replanning activities are also encompassed by 
the flow. The flow accommodates a multidiscipline payload complement but 
includes a unique path for a payload complement of co-all gned IPS-mounted 
stellar observation experiments. 

The SL mission planning process activities depicted in the 
Spacelab Functional Flow diagram are grouped into nine (9) major functions. 
These functions are: 

o Payload Data Collection 

o Orbi t Analysis 

o Mission Timeline Analysis 

o Flight Definition Document Development 

o Flight Planning Annex Input Development 

o Crew Procedures Development 

o Data Flow Analysis 

o MMU Load Input Development 

o Experiment Command Planning Development 

2.2.2 Spacelab Detailed Flow Diagrams 

The SL mission planning process detailed flows break down the 
functions to a subfunction/task/subtask level necessary to understand the 
mission planning activities, or to a level necessary to correlate a particular 
software module to an activity. 
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Activities may be manual, automated, or a combination of manual 
and automated. Manual activities normally include the collection of 
information (verbal inputs, informal or formal documentation), the evaluation 
and assessment of this information, and the publication of the results 
(informal or formal documentation). However, some manual activities produce a 
computerized input for a subsequent activity - e.g., use of the VAX editor to 
create a computerized file for use by a software module in a subsequent 
automated activity. 

Automated activities include a software module, based on some 
fixed algorithm, which reads a computerized input file(s) (fixed format), 
performs specific operations on the input data, and then outputs the results 
as either a computerized output file(s) or as a printout. Some automated 
activities require, or permit, manual inputs to the software module via a 
keyboard . 


Figures 2. 2. 2-1 and 2. 2. 2-2 are representative examples of the 
detailed flow diagrams developed to fully define the Spacelab payload mission 
planning process. Figure 2. 2. 2-1 provides a more detailed definition of 
(i.e., identifies the flow of tasks which comprise) the orbital analysis 
subfunction "Experiment Opportunities Generation" from the top-level Spacelab 
Functional Flow Diagram (Figure 2.2. 1-1). In turn, Figure 2. 2. 2-2 identifies 
the flow of subtasks which comprise the task "Generate Plasma Physics Targets" 
from Figure 2. 2. 2-1. Shown in these figures are manual /automated activities 
and associated manual /automated inputs/outputs. For each automated subtask in 
Figure 2. 2. 2-2, the name of the SL MIPS software module used to accomplish the 
subtask is indicated in the lower right-hand corner of the subtask block. 

2.3 SPACELAB MIPS DATA BASE 


The SL MIPS data base was developed in order to provide activity 
summary data, software description and requirements data, and activity time 
and skill requirements data. The level of detail of the data base is 
consistent with the level of detail in the Spacelab mission planning process 
detailed flow diagrams; that is, entries exist in the data base corresponding 
to each lowest-level activity block identified in the flow diagrams. In 
conjunction with the detailed flows, the data base provides a comprehensive 
definition of the Spacelab payload mission planning process. 

The data base consists of eight (8) interrelated tables of data: 

o Activity Summary Data 
o Activity Time and Skill Requirements 
o Software Used by Activity 
o Software Description 
o Software Peripherals Required 
o Activity Input/Outputs 
o Computer Input/Output Summary 
o Manual Input/output Summary 

Figures 2.3-1 through 2.3-8 provide representative examples of 
the data in these tables. The outlined entries correspond to the subtask 
"Develop/Apply Constraints to BORB Parameters". 
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FUNCTION: ORBITAL ANALYSIS 

SUBFUNCTION: EXPERIMENT OPPORTUNITIES GENERATION 
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FIGURE 2. 2. 2-1. EXPERIMENT OPPORTUNITIES GENERATION 















FUNCTION: ORBITAL ANALYSIS 

SUBFUNCTION: EXPERIMENT OPPORTUNITIES GENERATION 
TASK: GENERATE PLASMA PHYSICS TARGETS 
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FIGURE 2. 2. 2-2. GENERATE PLASMA PHYSICS TARGETS 
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FIGURE 2.3-1. RESOURCE REQUIREMENTS DATA BASE/ACTIVITY SUMMARY DATA 




CALENDAR SKILL LEVEL MANPOWER 

ACTIVITY CYCLE TIME (DAYS) SKILL TYPE (1-MOV,2-PRO,3-E)IP) (HRS) 
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FIGURE 2.3-2. RESOURCE REQUIREMENTS DATA BASE/ACTIVITY TIME AND SKILL REQUIREMENTS 
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FIGURE 2.3-3. RESOURCE REQUIREMENTS DATA BASE/SOFTWARE USED BY ACTIVITY 



SOFTWARE DESCRIPTION DATE 03/17/87 
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FIGURE 2.3-4. RESOURCE REQUIREMENTS DATA BASE/SOFTWARE DESCRIPTION 



SOFTWARE PERIPHERALS REQUIRED DATE 03/17/87 
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FIGURE 2.3-5. RESOURCE REQUIREMENTS DATA BASE/SOFTWARE PERIPHERALS REQUIRED 



ACTIVITY INPUT/OUTPUTS DATE 05/19/87 
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FIGURE 2-3.6. RESOURCE REQUIREMENTS DATA BASE/ACTIVITY INPUTS/OUTPUTS 



FILE SIZE(BYTES) 

INPUT/OUTPUT NAME MAXINUN MINIMUM INPUT/OUTPUT DESCRIPTION 
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IMPUT/OUTPUT NAME TYPE OOOMENT INCLUDED IN INPUT/OUTPUT DESCRIPTION 



FIGURE 2.3-8. RESOURCE REQUIREMENTS DATA BASE/MANUAL INPUT/OUTPUT SUMMARY 



THIS PAGE INTENTIONALLY LEFT BLANK 


2-15 



Section 3 


SPACE STATION MISSION PLANNING CONCEPT 
AND SOFTWARE REQUIREMENTS 

3.1 ACTIVITIES AND ACCOMPLISHMENTS 

The objective of this task was to develop a payload mission 
planning concept consistent with the overall Space Station operations 
philosophy and to define a system of software requirements maximizing use of 
the SL MIPS software modules (modified as necessary) to implement the concept 

The approach taken to this task consisted of four subtasks. 
First, basic definitions, groundrules, and assumptions were established; these 
pertained to the current Space Station design and operations concepts and 
philosophies, the scope of mission planning for Space Station, 
objectives/requirements to be achieved/satisfied by the approach to mission 
planning, the structure of organizations/personnel Involved in mission 
planning, the number, purpose, and nature of planning cycles for Space 
Station, and the degree of allocation of mission planning functions between 
ground-based organizations and the on-board crew. The second subtask involved 
the construction of a set of functional flow diagrams. The third subtask then 
involved the identification of modified SL MIPS software modules or new 
computer programs to automate individual mission planning activities 
identified in the flow diagrams. The fourth and final subtask involved the 
summarization and systemization into a hierarchical structure of the new or 
modified SL MIPS software programs as the basis for preparation of a software 
development plan in Task 5. 

Inputs to this study task were derived from a variety of sources 

o Space Station Program reference documents 

o Space Station plans, study reports, white papers, 
briefings, meeting minutes, etc., published by NASA 
organizations, contractors, and working groups, 
including the NASA Space Station Operations Task Force 
and its panels 

o Task 2 products and knowledge pertaining to the Spacelab 
mission planning process 

The products of this task consist of the Space Station payload 
mission planning concept functional flow diagrams, a summary table 
describing the new and modified SL MIPS software modules required to 
implement the SS MPS concept, and the hierarchical structure of software for 
the SS MPS. 

3.2 SS MPS CONCEPT FUNCTIONAL FLOWS 


Similar to the Spacelab functional flow diagrams, the SS mission 
planning concept functional flow diagrams show mission planning cycles and 
activities by organization and define the interfaces between those 
organizations; define a hierarchy of mission planning subfunctions, tasks and 
subtasks; reveal recurring mission planning activities across cycles; and. 
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identify applicable SL payload MIPS software modules or requirements for new 
software. The SS MPS Top Level Functional Flow is illustrated in Figure 

3.2- 1. Examples of the detailed flow diagrams for the subsequent levels are 
presented in Figures 3.2-2 through Figure 3.2-4. 

3.3 SOFTWARE REQUIREMENTS 

The hierarchical structure of required SS MPS software modules 
is shown in Figure 3.3-1; the structure is oriented toward the using 
organizations, and identifies (per the legend) the modified SL MIPS, new and 
Al-appl ication candidate software programs (Section 4 summarizes the approach 
and rationale supporting the AI application candidates). 

Representative excerpts from the summary table describing the 
new and modified SL MIPS software modules are presented in Figure 3.3-2 (Note 
the correlation of each software module to applicable subfunctions/tasks in 
the SS mission planning concept functional flow diagrams). 

For the purposes of assessing the applicability of AI techniques 
to the SS MPS in Task 4 of the study, and for generating the Software 
Development Plan in Task 5, the computer programs identified in Figure 3.3-1 
were grouped into software sets, i.e., groups of programs of a similar nature 
at the same hierarchical level. The software sets are presented in Table 

3.3- 1 . 
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SPACE STATION (SS) 

PAYLOAD MISSION PLANNING SYSTEM (MPS) 
TOP LEVEL FUNCTIONAL FLOW 
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C-GENERATE EXECUTION PLANS 
(MISSION INCREMENT) 



FIGURE 3.2-2. EXCERPT OF PLANNING CYCLE LEVEL FUNCTIONAL FLOWS 
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SUBFUNCTION. 5(USER)-SPECIAL OBSERVATION OPPORTUNITIES GENERATION 
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FIGURE 3.2-3. EXCERPT OF SUBFUNCTION LEVEL FUNCTIONAL FLOWS 
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riON: 3-SPECIAL OBSERVATION OPPORTUNITIES GENERATION 
-GENERATE PLASMA PHYSICS OBSERVATION OPPORTUNITIES 
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SS MPS SW HIERARCHY 

(USERS, PLNQ CTR AND PLD OPS INTEGRATION CTR) 



FIGURE 3.3-1. SS MPS SW Hierarchy 
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SS MPS SOFTWARE REQUIREMENTS SUMMARY page 4 
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FIGURE 3.3-2. EXCERPT OF SS MPS SOFTWARE REQUIREMENTS SUMMARY TABLE 
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FIGURE 3.3-2. EXCERPT OF SS MPS SOFTWARE REQUIREMENTS SUMMARY TABLE (CONT'D) 








TABLE 3.3-1. SS MPS SOFTWARE SETS 


NEW SOFTWARE MODIFIED SL MIPS SOFTWARE 


SET A - SPECIAL OBS OPPS EXECUTIVES 
TOP LEVEL 
ATMOS PHYS 
SOLAR 

EARTH SITE 
PLASMA PHYSICS 
CELESTIAL 
SET B - URDB I/F 

SET C - EDITOR EXECUTIVES 

MODEL EDITOR EXEC 
OBS OPPS EDITOR EXEC 
SCHEDULER EXEC 


SET D - RE-SCHEDULER 


SET E - SYSTEM EXECUTIVES (PHASE I) 
USER MPS EXEC 
PLANNING CENTER MPS EXEC 
POIC MPS EXEC 

SET F - SYSTEM EXECUTIVES (PHASE II) 
USER MPS EXEC 
PLANNING CENTER MPS EXEC 
POIC MPS EXEC 
SET G - COMMAND PLANNER 
SET H - NEW TIMELINE ANALYSIS MODULES 
MDL EXTRACT 
MDL COMPARE 
TL COMPARE 
TL MERGE 
PCAP DELTAS 
SUMMARY PCAP 

SET L - OUTPUT PROCESSOR EXEC 


SET I - TIMELINE ANALYSIS 
ESP 
PCAP 
PTS 
TAE 
VME 

SET J - ORBIT ANALYSIS 
ASEP 
ATMOS 
BORB 
CAVA 
ESAL 
ESDATA 
LTO 
RADI 2 
STAR 
TANRAY 
TARGEN 

SET K - DATA FLOW ANALYSIS 
PROFILE 

MISSION WINDOWS 

ONBOARD RECORDER SCHEDULAR 

POSSIBLE FORMATS 

FORMAT SCHEDULAR 

POSSIBLE POCC CONFIGURATIONS 

POCC CONFIGURATION SCHEDULAR 

PLAYBACK SCHEDULAR 

INTERACTIVE DATA UPDATE SYSTEM 

VERIFICATION 

COMPARE TDRS 

COMPARE MODELS 

DATA MANAGEMENT CHECKLIST 

DATA SCHEDULE FILE 

ANTENNA DISPLAY 

IDMS LIBRARY 


3-1 



THIS PAGE INTENTIONALLY LEFT BLANK 



Section 4 


ARTIFICIAL INTELLIGENCE APPLICATIONS 
4.1 ACTIVITIES AND ACCOMPLISHMENTS 


The objectives of this task were to: 

(1) Define AI techniques that could be applied to SS MPS tasks. 

(2) Identify and evaluate all tasks that could use the AI 
techniques. 

(3) Recommend a methodology for Implementation of the 
identified AI tasks. 

These objectives were accomplished as illustrated in Figure 
4.1-1. Two areas of effort contributed to accomplishment of the objectives 
specified above. The first effort was to conduct a survey of the current AI 
technology. The second effort was to compile a list of desired criteria for 
an AI software development program. Both efforts increased the quality and 
scope of the recommended hardware and software methodology. 

4.2 DEFINITION OF ARTIFICIAL INTELLIGENCE 

Artificial Intelligence is the emulation of human intelligence 
and thought processes by computational models. It is the branch of Computer 
Science concerned with designing intelligent computer systems that exhibit the 
characteristics associated with intelligence in human behavior - reasoning, 
understanding language, solving problems, etc. 

Expert systems are AI programs that are designed to execute a 
highly specialized and difficult task with the proficiency of a human expert. 
They employ domain-specific problem-solving strategies as opposed to broad, 
general-purpose strategies. 
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FIGURE 4.1-1. AI TASK FLOW 
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ASSUMPTIONS PRIOR TO CANDIDATE EVALUATION 


Experience gained from the early phases of the project allowed 
several assumptions to be made prior to evaluation of the SS MPS candidates. 

4.3.1 ADA Software 


It is assumed that all new non-AI mission planning software 
tasks will be coded in ADA for compatibility with Space Station program 
requirements. 


All AI techniques can be implemented In LISP, PROLOG or ADA. 
LISP and PROLOG have only a few advantages over ADA. 

4.3.2 Specialized AI Hardware 


If specialized AI hardware Is required, assume a Symbolics 
architecture. LISP and PROLOG are not viable languages unless executed on 
specialized AI processors. Symbolics is the best processor currently on the 
market. 


The execution of LISP on coprocessor boards installed in 
conventional computers is not considered; however, their emergence on the 
market is imminent. 

4.3.3 Conventional Hardware 


Assume a DEC VAX architecture for all ADA software 
implementations. 

4.3.4 Candidate Evaluation Criteria 

The criteria for candidate evaluation are not discrete. They 
are frequently interrelated. 

The criteria are qualitative rather than quantitative. Also, 
not all criteria are of equal importance. 

The evaluation of each software set against the criteria is 
subjective. The evaluation is highly dependent on definitive information 
about AI techniques and Space Station operations concepts. 

4.4 DESIRED ATTRIBUTES OF MPS TASKS 


This list of desired attributes is based upon industry accepted 
standards for a software development project. Several attributes have been 
added or modified to tailor them to software projects employing AI techniques. 

The desired attributes for candidate MPS tasks are shown in 
Figure 4.4-1. Each software set received a "+" if the set contained the 
desired attribute and a if the attribute was missing and could cause 
potential problems in the implementation of the task. 
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ATTRIBUTES OF MPS TASKS 


TASK GROUP 

ABCOEFGH I J K L 


Domain is bounded and stable 

5 

5 
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fl 

fl 

B 

E 

B 

fl 
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fl 

B 

Domain Is specialized and detailed 

a 
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fl 
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fl 

B 

B 

B 

B 
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B 

Expertise to be lost 

a 

a 

a 

fl 

a 

a 

B 

B 

B 

B 

B 

B 

Expertise is scarce 

a 

B 

B 

B 

B 
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B 
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B 
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Expert is dedicated 
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System can monitor real world 

a 

fl 

fl 

fl 

B 

B 

B 

B 

B 

B 

B 

B 

I /O and methods can be defined 

B 

B 

B 

fl 

B 

B 

B 

B 

B 

B 

B 

B 

Debugging the software 

a 

□ 

B 

B 

fl 

B 

D 

B 

B 

B 

B 

E 

Required Documentation 

5 

5 

fl 

5 

fl 

B 

a 

5 

fl 

5 

5 

B 

Configuration control 

a 

B 

B 

B 

B 

B 

B 

B 

fl 

B 

B 

B 

System acceptance testing 

a 

fl 

a 

a 

fl 

B 

fl 

B 

fl 

B 

B 

B 

Realistic schedules and milestones 

5 

B 

fl 

5 

fl 

5 

5 

B 

B 

B 

B 

B 

Resource comittment 

a 

B 

B 

B 

fl 

B 

B 

B 

B 

B 

B 

B 

Low initial cost 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

B 

E 

Long term manhour savings 

a 

□ 

fl 

fl 

fl 

B 

B 

B 

B 
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B 

E 

User acceptance 

5 

a 

B 
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fl 

B 
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B 

B 
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SOFTWARE SETS 


A - SPECIAL OBS OPPS EXECUTIVES 

B - USER REQUIREMENTS DATA BASE INTERFACE 

C- EDITOR EXECUTIVES 

D- RESCHEDULER 

E - SYSTEM EXECUTIVES PHASE I 

F - SYSTEM EXECUTIVES PHASE II 


0 - COMMAND PLANNER 
H - NEV TIMELINE SOFTVARE 
I -MODIFIED TIMELINE SOFTVARE 
J - MODIFIED ORBITAL MECHANICS SOFTVARE 
I- MODIFIED DATA FLOV SOFTVARE 
L - OUTPUT PROCESSOR EXECUTIVE 


FIGURE 4.4-1. ATTRIBUTES OF MPS TASKS 
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ARTIFICIAL INTELLIGENCE TECHNIQUES 


An attempt was made to comb through the many books describing AI 
techniques and pull out the techniques that demonstrate advantages over 
conventional programming techniques. 

The definition of an AI technique versus a conventional 
technique is subjective and a source of disagreement within the programming 
community. The boundary between the two is constantly shifting. Many AI 
techniques were first implemented in LISP or PROLOG and then found their way 
to conventional implementations in FORTRAN, PASCAL or C. For our definition, 
AI techniques are most easily implemented in ADA, LISP or PROLOG, while 
Implementations in FORTRAN, etc., are considered to be strictly conventional. 
Note that ADA holds the middle ground, being a derivative of PASCAL and 
FORTRAN, but designed to easily implement complex AI techniques. 

The AI techniques identified as advantageous over conventional 
programming techniques are listed on Figure 4.5-1. The functions of each 
software set were evaluated against the list and given a "+" if any of the 
task functions could be implemented using an AI technique. 

4.6 METHODOLOGY FOR CANDIDATE IMPLEMENTATION 


The methodology for hardware and software host selection is 
illustrated in Figure 4.6-1. The software sets were evaluated against the 
attributes described below and given a "+" if they exhibited a need for that 
attribute. They were given a if they had no need for that attribute. 


( 

4.7 


RESULTS OF EVALUATION 


The evaluation of each SS MPS task against the Desired 
Attributes criteria produced a list of benefits and concerns for the 
implementation of each software set. 

The summation and weighing of all evaluations performed 
previously, resulted in the task methodology recommended for implementation. 
This recommendation is shown on the bottom half of Figure 4.6-1. 

Fourteen tasks were selected as candidates for using AI 
techniques. Thirteen tasks are recommended to be delivered in ADA on the VAX. 


One task is recommended to be delivered on the Symbolics in LISP 
with a hardware interface to the VAX. At a future date it should be ported to 
the VAX prior to installation on-board the Space Station. 


Machine. 

MIPS. 


Four tasks are recommended for prototyping on the Symbolics 
Three tasks are recommended for implementation in the Spacelab 
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AI TECHNIQUES FOR MPS TASKS 

TASK GROUP 

ABCDEFGH IJKL 



SOFTWARE SETS 

A - SPECIAL OBS OPPS EXECUTIVES G - COMMAND PLANNER 

B - USER REQUIREMENTS DATA BASE INTERFACE H - NEV TIMELINE SOFTVARE 
C - EDITOR EXECUTIVES I -MODIFIED TIMELINE SOFTVARE 

D - RESCHEDULER J - MODIFIED ORBITAL MECHANICS SOFTVARE 

E - SYSTEM EXECUTIVES PHASE I I- MODIFIED DATA FLOV SOFTVARE 

F - SYSTEM EXECUTIVES PHASE II L - OUTPUT PROCESSOR EXECUTIVE 


FIGURE 4.5-1. AI TECHNIQUES FOR MPS TASKS 
4-6 























A I METHODOLOGY FOR MPS TASKS 
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SOFTWARE SETS 


1 - SPECIAL OBS OPPS EXECUTIVES 

B - USER REQUIREMENTS DATA BASE INTERFACE 

C- EDITOR EXECUTIVES 

D- RESCHEDULER 

E- SYSTEM EXECUTIVES PHASE I 

F - SYSTEM EXECUTIVES PHASE II 


G - COMMAND PLANNER 
H - NEV TIMELINE SOFTVARE 
I -MODIFIED TIMELINE SOFTVARE 
J - MODIFIED ORBITAL MECHANICS SOFTVARE 
E- MODIFIED DATA FLOV SOFTVARE 
L - OUTPUT PROCESSOR EXECUTIVE 


FIGURE 4.6-1. AI METHODOLOGY FOR MPS TASKS 
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4.8 


CONCLUSIONS AND RECOMMENDATIONS 


4.8.1 AI Technology 

AI technology is still very young. The experience base of 
expert systems performance is small compared to conventional programs. 
However, the systems in existence do strongly support the many advantages of 
incorporating this technology into the workplace. AI has proven effective in 
solving many of the problems where conventional programs fail. 

4.8.2 Hardware/Software Architecture 


The conclusion to largely use ADA on a VAX is also supported by 
a study conducted by MDAC-HB for the JSC Space Station Phase B contract. 

The largest value of LISP and PROLOG is in the rapid prototyping 

environment. 

4.8.3 Software Tools 


Use is recommended during prototyping of an expert system 
development tool and a natural language development tool. 

An In-depth technology survey, with the targeted MPS candidates 
in mind, should be performed Immediately prior to purchase of any 
off-the-shelf AI tools. 
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Section 5 


SOFTWARE DEVELOPMENT PLAN 


5.1 TASK OVERVIEW 


The objective of this task was to generate a Software 
Development plan for the definition, design and implementation of the SS MPS. 

The approach taken to this task consisted of four subtasks. 
First, assumptions inherent in the generation of the SW Development Plan were 
identified; these pertained to SW development facilities, computer operating 
systems, coding languages and standards, required formal reviews, required 
documentation, etc. The second subtask Involved developing a technical 
description of the project - SW requirements, SW hierarchy, etc., and a 
detailed description of the activities required to successfully complete the 
development project. Based on the assumptions of subtask 1 and the 
descriptions of subtask 2, subtask 3 was performed to generate cost estimates 
for individual or sets of required SS MPS computer programs in terms of 
manpower and schedule using the Constructive Cost Model (COCOMO), and 
integrating these into project level manpower requirements and schedule 
recommendations. The fourth and final subtask was to document and publish the 
SW Development Plan. 

Inputs to this study task were derived from: 

o Task 3 products (SS MPS Functional Flows and SW 
Requirements Summary) 

o Task 4 products (AI recommendations and implementation 
requirements) 

o COCOMO Model 

o Existing SW development plans (boilerplates) 

The product of this task is the SS MPS SW Development Plan, 
which constitutes Volume III of the Study final report. 

5.2 SOFTWARE DEVELOPMENT PLAN DESCRIPTION 


The SW Development Plan includes an introduction, a technical 
description of the project, a detailed description of the project activities, 
the SW development schedules, manpower requirements and an explanation of the 
methodology and assumptions utilized for the estimates, and a detailed 
description of the SW procedures and practices recommended to be applied to 
the project. 


The recommended SS MPS Project Top Level Schedule is shown in 
Figure 5.2-1. Representative lower level schedules for individual software 
sets are shown in Figure 5.2-2. The estimated manpower requirements are 4841 
man months for the entire project. If the SS MPS was developed without the 
benefit of the Spacelab MIPS software the estimated total is 9612 manmonths. 
Representative excerpts of the manpower requirements by project phase for 
individual software sets are shown in Figure 5.2-3. 


3- I 




5-2 













FIGURE 5.2-2. REPRESENTATIVE SS MPS LOWER LEVEL SCHEDULES 
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Section 6 




CONCLUSIONS AND RECOMMENDATIONS 

Based on the results of the SS MPS Development Study summarized 
in the previous sections, the following conclusions have been drawn: 

1) A detailed definition of the Spacelab payload mission 
planning process and SL MIPS software has been derived; this definition 
(functional flow diagrams and data base) will be of great value for training 
Spacelab mission planning personnel and for assessing and Improving the 
process. 


2) A baseline concept for performing SS manned base payload 
mission planning has been developed; this concept is consistent with current 
Space Station design/operations concepts and philosophies; however, those 
concepts and philosophies are the results of Phase B studies and will 
therefore gain further definition and changes as the Space Station Program 
progresses. 


3) SS MPS software requirements have been defined. These 
software requirements make maximum use of SL MIPS software with modifications, 
but do include requirements for new software to accommodate the complexity of 
the SS mission planning concept and to maximize automation of the concept. 
Also, requirements for new software include candidate programs for the 
application of AI techniques to capture and make more effective use of mission 
planning expertise and to involve SS users directly in the mission planning 
process. 

4) A SS MPS Software Development Plan has been developed which 
phases efforts for the development of software to implement the SS mission 
planning concept. The efforts are phased for the Immediate start of 
development of long-lead-time software programs, but for delayed development 
of programs with a high dependence on SS design/operations concepts. The 
development schedule, relative to the current overall Space Station Program 
schedule, indicates the development effort should begin as soon as possible. 

5) The estimated manpower requirements to develop the SS MPS 
are significant; however, the scope of the SS mission planning problem is 
significant and the process of development is recommended to be highly 
structured and rigidly controlled. Nonetheless, the software system concept 
is intended to provide uniform methods of planning payload operations across 
all equivalent planning levels in order to facilitate the integration of 
planning, and is intended to maximize the automation of mission planning to 
minimize long-term mission planning costs. 

Based on the conclusions above, the following recommendations 

are offered: 


1) Use the definition (functional flows and data base) of the 
Spacelab payload mission planning process and software to train mission 
planning personnel and to evaluate and improve the process. As improvements 
are made, update the flow diagrams and data base. 
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2) Proceed with implementation of the SS MPS Development Plan, 
including the structured and controlled process for software development. 

3) Maintain the SS mission planning concept, software system 
concept, and Software Development Plan consistent with SS design/operations 
concepts and program schedules. 

4) Use Spacelab mission planning as a test bed for testing 
prototypes of AI applications. 
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